In the field of application servers and distributed systems, clusters of servers are often used to provide highly available and scalable resources. One example of an application server is the WebLogic Server from BEA Systems, Inc. A cluster (such as a WebLogic Server cluster) comprises multiple server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single server. The server instances that constitute a cluster can run on the same machine, or be located on different machines. A cluster's capacity can be increased by adding additional server instances to the cluster on an existing machine, or by adding machines to the cluster to host the incremental server instances. Each server instance in a cluster must typically run the same version of the server product.
In terms of how a cluster relates to the environment in which the application server exists, a cluster is usually part of a particular server (e.g. WebLogic Server) domain. A domain is an interrelated set of resources that are managed as a unit. A domain includes one or more server instances, which can be clustered, non-clustered, or a combination of clustered and non-clustered instances. A domain can include multiple clusters. A domain also contains the application components deployed in the domain, and the resources and services required by those application components and the server instances in the domain. Examples of the resources and services used by applications and server instances include machine definitions, optional network channels, Java 2 Enterprise Edition (J2EE) components, Enterprise Java Bean (EJB), connectors, and startup classes. An administrator can use a variety of criteria for organizing server instances into domains. For instance, they might choose to allocate resources to multiple domains based on logical divisions of the hosted application, geographical considerations, or the number or complexity of the resources under management.
In a WebLogic domain, one WebLogic Server instance typically acts as the Administration Server—the server instance which configures, manages, and monitors all other server instances and resources in the domain. Each Administration Server manages one domain only. If a domain contains multiple clusters, each cluster in the domain has the same Administration Server. All server instances in a cluster must reside in the same domain; i.e. you cannot “split” a cluster over multiple domains. Similarly, you cannot share a configured resource or subsystem between domains. For example, if you create a Java Database Connectivity (JDBC) connection pool in one domain, you cannot use it with a server instance or cluster in another domain. (Instead, you must create a similar connection pool in the second domain.).
Clustered server instances behave similarly to non-clustered instances, except that they provide failover and load balancing. The process and tools used to configure clustered server instances are the same as those used to configure non-clustered instances. A server cluster provides the following benefits and features:
Scalability—The capacity of an application deployed on a cluster can be increased dynamically to meet demand. Server instances can be added to a cluster without interruption of service—the application continues to run without impact to clients and end users.
High-Availability—In a cluster, application processing can continue when a server instance fails. Application components are “clustered” by deploying them on multiple server instances in the cluster-so, if a server instance on which a component is running fails, another server instance on which that component is deployed can continue application processing.
Failover—Failover means that when an application component (typically referred to as a “service” in the following sections) doing a particular “job”—some set of processing tasks-becomes unavailable for any reason, a copy of the failed service finishes the job. For the new service to be able to take over for the failed service there must be a copy of the failed service available to take over the job. There must also be information, available to other services and the program that manages failover, defining the location and operational status of all services-so that it can be determined that the first service failed before finishing its job. There must also be information, available to other services and the program that manages failover, about the progress of jobs in process—so that a service taking over an interrupted job knows how much of the job was completed before the first service failed, for example, what data has been changed, and what steps in the process were completed. Many application servers, including WebLogic Server, use standards-based communication techniques and facilities-multicast, IP sockets, and the Java Naming and Directory Interface (JNDI)—to share and maintain information about the availability of services in a cluster. These techniques allow the server to determine that a service stopped before finishing its job, and where there is a copy of the service to complete the job that was interrupted. Information about what has been done on a job is called state. WebLogic Server maintains information about state using techniques called session replication and replica-aware stubs. When a particular service unexpectedly stops doing its job, replication techniques enable a copy of the service to pick up where the failed service stopped, and finish the job.
Load Balancing—Load balancing is the even distribution of jobs and associated communications across the computing and networking resources in the application server environment. For load balancing to occur there must be multiple copies of a service that can do a particular job. Information about the location and operational status of all services must also be available. In addition, WebLogic Server allows services to be clustered—deployed on multiple server instances—so that there are alternative services to do the same job. WebLogic Server shares and maintains the availability and location of deployed services using multicast, IP sockets, and JNDI.
A clustered application or application component is one that is available on multiple server instances in a cluster. If a service is clustered, failover and load balancing for that service is available. Web applications can consist of different types of services, including Enterprise Java Beans (EJBs), servlets, and Java Server Pages (JSPs). Each service type has a unique set of behaviors related to control, invocation, and how it functions within an application. For this reason, the methods that WebLogic Server uses to support clustering—and hence to provide load balancing and failover—can vary for different types of services. The following types of services can be clustered in a WebLogic Server deployment: Servlets; JSPs; EJBs; Remote Method Invocation (RMI) objects; Java Messaging Service (JMS) destinations; and, Java Database Connectivity (JDBC) connections.
Different service types can have certain behaviors in common. When this is the case, the clustering support and implementation considerations for those similar service types may be same. In the sections that follow, explanations and instructions for the following types of services are generally combined: Servlets and JavaServer Pages (JSP); and EJBs and RMI objects. The sections that follow briefly describe the clustering, failover, and load balancing support that WebLogic Server provides for different types of services.
Servlets and JSPs
WebLogic Server provides clustering support for servlets and JSPs by replicating the Hypertext Transfer Protocol (HTTP) session state of clients that access clustered servlets and JSPs. WebLogic Server can maintain HTTP session states in memory, a filesystem, or a database.
EJBs and RMI Objects
Load balancing and failover for EJBs and RMI objects is handled using replica-aware stubs, which can locate instances of the service throughout the cluster. Replica-aware stubs are created for EJBs and RMI objects as a result of the service compilation process. EJBs and RMI objects are deployed homogeneously—to all the server instances in the cluster. Failover for EJBs and RMI objects is accomplished using the service's replica-aware stub. When a client makes a call through a replica-aware stub to a service that fails, the stub detects the failure and retries the call on another replica.
JDBC Connections
WebLogic Server allows you to cluster JDBC services, including data sources, connection pools and multipools, to improve the availability of cluster-hosted applications. Each JDBC service you configure for your cluster must exist on each managed server in the cluster.
JMS
The WebLogic Java Messaging Service (JMS) architecture implements clustering of multiple JMS servers by supporting cluster-wide, transparent access to destinations from any WebLogic Server server instance in the cluster. Although WebLogic Server supports distributing JMS destinations and connection factories throughout a cluster, the same JMS topic or queue is still managed separately by each WebLogic Server instance in the cluster.
However, even given the successes of clustering in the application server environment, a typical problem with today's clustered systems is that they do not suitably address the number of external client connections they handle. Method calls are typically load balanced among the available server instances according to the configured load balancing algorithm. As a result a large number of sockets must be opened and maintained between the external clients and server instances in the cluster. A new approach that disables traditional load balancing for external client connections, but still allows it for less costly server-to-server connections would be of great use in enhancing cluster stability and scalability.